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ms^intained. Each entity has a unique handle. The identity of the presence server 
maintaining presence information for the entity can be detennlned from the handle. A 
haijidle is well known name for an entity. An example of a handle is 
ppWwww.lntercom, att.com/TyrantRana. Finally, a point of presence (PoP) is defined 
as la point of presence for an entity. If an entity Is present, it is connected to one 
Pop. Each PoP has an address, e.g., an IP address and a port number, at which 
prejsence messages may be delivered.— 






Please replace the paragraph beginning at page C^ine 19, with the follov^ing 
rewritten paragraph: 






- 

pre 
lnt< 
dis 
oni 
the 
sta 


-There are currently models, including the models described above, that 
vide for instant messaging (IM) and presence services within the scope of an 
jrnet Protocol / data network environment. It will be appreciated from the 
cussion above that one of the key elements of IM operation involves the ability for 

» cnhcrrihor fn "IrnnxA/" u/hon anrtth^r QiihQrrihAr iQ Innn^H in or "flvflilflhlp " From 

discussion above, it will also be appreciated that the ability^ to track the login 
tus, othenwise known as "presence," of Internet users is fairly well developed and 




wic 

to 

cor 

cor 

dig 

cor 

sut 

sut 

me 

sei 


ely practiced, However, as communication networking technology has continued 
evolve at a rapid pace, so have the means by which end users or subscribers can 
nmunicate. More particularly, the explosive growth of hand-held, wireless 
nmunication terminals, such as cell phones, wireless Web phones, and personal 
ital assistants has led to a demand for inter-networking or inter-medium 
nmunication solutions. In other words, it is rapidly becoming useful for a 
)scriber~ta have his or her wireless phone status or "presence" known to other 
)scribers, where these other subscribers may be using a variety of communication 
diums, such as wireless phone service, wired phone service, short message 
vice (SMS), or Internet service.- 




rev 


Please replace the paragraph beginning at page 7, line 20, with the following 
mtten paragraph: 






inc 


-According to another aspect, a presence registration and routing node 

ludes an advanced database communications module (ADCM) for receiving 
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queries for presence information. The ADCM module fonwards the queries to a 
prejsence application, such as a SIP, IMPP, or presence application. The presence 
api|)lication formulates a presence-server-compatible message, forwards the 
pr^sence-server-compatibie message to a presence database, receives a response 
frojn the database, and fonwards the response to the ADCM module to be sent to the 
recjuestor over an IP network. The presence database may be internal or external to 



the 



presence registration and routing node.- 



Please replace the paragraph beginning at page 9, line 23, with the following 
revj^ritten paragraph: 



be 



message according to an embodiment of the present invention;- 



-Figures 5(A) and 5(B) are a flow chart illustrating exemplary steps that may 
perfomied by a presence registration and routing node in processing an lAM 



Please replace the paragraph beginning at page 10^^ line 22, with the following 
revj^ri tten paragraph: J, 



-Figure 13 is a block diagram of a presence registration and routing node 
including an external presence database according to an embodiment of the present 
invlention;- 



_ 

Please replace the paragraph beginning at page 13, line 16, with the following 

revj/ritten paragraph: 




-Shown in Figure 3 is a schematic diagram of a presence registration and 

roijting node 300 of the present invention. It will be appreciated that presence 

registration and routing node 300 includes a high speed Interprocessor Message 

Trginsport (IMT) communications bus 310. Communicatively coupled to IMT bus 310 

arei a number of distributed processing modules or cards including a pair of 

Maintenance and Administration Subsystem Processors (MASPs) 312, an SS7 

capable Link Interface Module (LIM) 320, an IP capable Advanced Database 

Communication Module (ADCM) 360, and a Presence Registration Module (PRM) 

341). These modules are physically connected to the IMT bus 310 such that signaling 

and other type messages may be routed internally between all active cards or 

mcdules. For simplicity of illustration, only a single LIM 320, ADCM 360, and PRM 
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34^ are included in Figure 3. However, it should be appreciated that the distributed, 
mtllti-processor architecture of the presence registration and routing node 300 
facjilitates the deployment of multiple LIM, ADCM, PRM, and other cards, all of which 
coijild be simultaneously connectedjto the IMT^us 310.- 



/2h 



Please replace the paragraph beginning at page 14, line^, with the following 
rewritten paragraph: 



I -Focusing now on LIM card functionality, it will be appreciated that LIM 320 is 
corjnprised of a number of sub-component processes including, but not limited to, an 
SS7 MTP level 1 process 322, an SS7 MTP level 2 process 324, an I/O buffer or 
queue 325, a gateway screening (GWS) process 326, a Presence Registration 
Request (PRR) stop action process 328, an SS7 MTP level 3 layer HMDC process 
330, and an HMDT process 332. MTP level 1 and 2 processes 322 and 324, 
resjpectively, provide the facilities necessary to send and receive digital data over a 
pajticuiar physical media / physical interface, as welt as to provide error detection / 
correction and sequenced delivery of all SS7 message packets. I/O queue 325 
provides for temporary buffering of incoming and outgoing signaling message 
packets. GWS process 326 is responsible for examining the incoming signaling 
message and detemriining which, if any, of the provisioned stop actions are 
applicable. PRR stop action process 328 is responsible for making a copy of and 
subsequently encapsulating an incoming SS7 ISDN User Part (ISUP) lAM signaling 
mejssage packet within an SS7 Signaling Connection Control Part (SCCP) fonnatted 
packet It should be appreciated that PRR stop action process 328 could also be 
configured to simply encapsulate the original incoming SS7 ISUP lAM signaling 
message, without making a copy. MTP level 3 HMDC process 330 receives 
signaling messages from the lower processing layers and perfonns a discrimination 
furjction, effectively determining whether an incoming SS7 message packet requires 
int<5rnal processing or is simply to be through switched. For instance, in the case of 
an SS7 TCAP message associated with presence registration or an SCCP 
en()apsulated ISUP lAM message, HMDC process 330 would detemriine that the 
message should be intemally routed for further processing. HMDT process 332 
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msjnages or directs the internal routing of SS7 message packets that require 
additional processing prior to final routing. Once again, it should be appreciated that 
a LjlM card may contain more functional processes than those described above. The 
abi^we discussion is limited to LIM functionality associated with the basic processing 
of jn-bound signaling messages.— 




Please replace the paragraph beginning at page 16, line 15. with the following 
rewntten oaraaraoh: 




pre 
rou 
cor 
Co 
Ma 

ge 

res 
pre 
pre 
Th 
25^ 
car 
sei 
del 
of) 


-In general, a PRM card includes the database and database control 
cesses necessary to achieve the presence registration message generation and 
ting functionality of the present invention. The PRM 340 shown in Figure 3 is 
nprised, in part, of an SCCP subsystem controller known as a Signaling 
nnection Routing Controller (SCRC) process 342, a Presence Registration 
nager (PRMG) process 344, and a number of Presence Registration Applications 
lerally indicated by reference numeral 346. Included among the presence 
istration applications Is a session initiation protocol (SIP) registration application 
cess 348 for generating SIP messages, fonwarding the SIP messages to a 
sence server, and processing SIP messages received from the presence server. 
3 fomnat for SIP messages is described in detail in the above-referenced RFC 
13, which defines the SIP protocol. In addition, the portion of a SIP message that 
ries the media capabilities information for an end user device is refen-ed to as the 
\s\on description protocol portion. The session description protocol is described in 
ail in RFC 2327, "SDP: Session Description Protocol," (April 1998), the disclosure 
vhich is incorporated herein by reference in its entirety.- 




rev 


Please replace the paragraph beginning at page"^ line 1 , with the following 
mtten paragraph: 




the 
pre 
ne: 
34^ 


-SCRC process 342 is responsible for discrimination of signaling messages at 

SCCP level, and for distributing the signaling messages to an appropriate higher 

cessing level application or function. In the configuration shown in Figure 3, the 

rt highest processing level is represented by PRMG process 344. PRMG process 

1 is responsible for determining how to process the incoming message packet. 
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Foj- instance, if the message packet contains an SCCP encapsulated ISUP lAM 
message, PRMG process 344 is configured to de-capsulate the original ISUP lAM 
message and subsequently extract the appropriate information necessary for further 
prqcessing from the de-capsulated message. However, if the incoming message 
we^'e a TCAP formatted packet, no de-capsulation action would be required. In either 
ca^e, PRMG process 344 is also charged with determining which of the provisioned 
presence registration applications is required for successful processing of a particular 
inc|oming signaling message packet. As will be appreciated from Figure 3, a number 
of l^resence registration applications may be simultaneously provisioned on a single 
Pr|mG card. These presence registration applications may be configured such that 
each application is capable of generating presence registration messages that are 
for^natted in different protocols including, but not limited to, SIP, IMPP, and presence 
prctocol.- 



Please replace the paragraph beginning at page 19, line tZ^with the following 
revfritten paragraph: 



-Referring to Figure 5(A), in step ST1, an incoming ISUP lAM message is 

i 

received at inbound LIM module 320. In steps ST2 and ST3, the incoming ISUP lAM 

message is received and processed by the MTP Level 1 and 2 processes 322 and 

324, respectively. With MTP Level 1 and 2 processing complete, the signaling 

message packet is temporarily buffered In the I/O queue 325 before being passed up 

the stack to the MTP Level 3 Gateway Screening (GWS) process 326. As indicated 

in step ST4, GWS process 326 examines the incoming ISUP lAM message and 

determines not only whether the message is to be allowed into the switch for further 

processing, but also which, if any, of the provisioned stop actions are applicable to 

the incoming message. In this example, GWS process 326 examines the incoming 

ISliP lAM message and determines that the message is permitted to enter the 

switch. Furthermore, upon examination of the Originating Point Code (OPC), 

Dekination Point Code (DPC) and Service Indicator Octet (SIO) fields contained in 

the MTP routing layer, it is detennined that the message requires additional 

processing by the PRR stop action 328 (ST5). In step ST6 PRR stop action process 
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32^ receives the ISUP lAM message from GWS process 326 and determines that the 
incoming message is an ISUP type MSU. The PRR stop action process 328 next 
checks the DPC of the incoming MSU. More specifically, the PRR stop action 
veififies that the DPC of the incoming MSU is a valid PC. PRR stop action 328 
examines the incoming MSU to determine whether presence registration service is 
recjuired. If the incoming MSU is identified as being an ISUP lAM type message, 
PRjR stop action 328 encapsulates a copy of the ISUP lAM message within an SCCP 
forfnatted MSU, as indicated in step ST6. Such SCCP encapsulation is effectively 
acrpieved by adding essential SCCP message leading and trailing bit sequences to 
the| base bit sequence that comprises the ISUP lAM MSU, as generally illustrated in 
Figlure 6. Thus, an SCCP type encapsulated MSU Is created which envelops or 
contains an ISUP type MSU, Subsequent to this encapsulation, the incoming 
message no longer appears or is treated as an ISUP lAM message within the 
pre sence registration and routing node 300, but is instead processed internally as an 
SCCP type SS7 message.- 



Please replace the paragraph beginning at page 21, line 8, with the following 
rewritten paragraph: 



-However, in the case where an incoming ISUP MSU satisfies the ST5 
critjeria, SCCP encapsulation of the ISUP MSU occurs and the resulting encapsulated 
MS U is directed to HMDC process 330 (ST7), where SCCP type processing is 
peiformed. In the example shown in Figure 3, HMDC process 330 examines the 
mejssage packet and determines that the DPC and Subsystem Number (SSN) of the 
SCCP packet is the point code of the presence registration and routing node. 
Consequently, further processing of the SCCP MSU within the routing node is 
asstumed to be necessary, and the packet is passed to HMDT process 332. HMDT 
prdcess 332 examines the Service Indicator (SI) field of the encapsulated MSU, 
wh ch indicates that the encapsulating packet is of an SCCP type. As such, HMDT 
process 332 places the encapsulated SCCP MSU on high speed IMT bus 310 for 
transport to PRM 340 and subsequent presence registration service.- 
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Please replace the paragraph beginning at page 21, (ine 21, with the following \ 

revpritten paragraph: ^ 

-Referring to Figure 5(B), in step ST8, the encapsulated SCCP MSU is 
recjeived and examined by SCRC process 342 that is resident on PRM 340. SCRC 
prc^cess 342 examines the message, detemiines that presence registration service is 
indicated, and forwards the encapsulated MSU to the PRMG process 344, as 
inculcated by step ST9. In step ST10, PRMG process 344 extracts the ISUP lAM 
M^U from the SCCP envelope and determines that the ISUP MSU requires the 
gejieration of a SIP-formatted presence registration message (ST11). The ISUP lAM 
M^U is subsequently directed to SIP application 348 for further processing (ST12). 
SIff application 348 examines the ISUP lAM MSU and, using information contained 
witjiin the MSU, generates a SIP-formatted presence registration message (ST13).— 

Please replace the paragraph beginning at page 22, line 7, with the following 

revprittenjDaragraph: ^ 

-With SIP processing complete, the SIP-formatted presence registration 
mejssage is passed to HMRT process 360. HMRT process 350 determines to which 
AD|cM card the SIP registration message packet should be routed for subsequent 
oulbound transmission (ST14). In this case, the HMRT process 350 determines that 
the desired outbound signaling link associated with the routing of the SIP registration 
message is located on ADCM 360. Consequently, the SIP message packet is 
int(jrnally routed across the IMT bus 310 to LIM 360, where it is received by I/O 
qu(sue 362 (ST15). Eventually, the modified message packet is passed from I/O 
qu(^ue 362 to the IP Level 2 and Level 1 processes 364 and 366, respectively 
(81 "16). Once again, IP level 1 and 2 processes 366 and 364, respectively, provide 
the! facilities necessary to send and receive digital data over a particular physical 
meldia / physical interface, as well as to provide error detection / connection and 
se(iuenced delivery of all IP message packets transmitted into the IP network. As 
indicated in step ST17, the SIP-formatted presence registration message is then 
transmitted into an IP network for ultimate delivery to and use by a presence 

database system.- 

I -8- 
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r""""^ ^lease replace the paragraph beginning at page^22, line 24, with the following^ 

/ revt^ritten paragraph: J 

"^-^ -It will be appreciated that the registration message generation methodology 
shtpwn in Figure 4 Is fundamentally similar to the process indicated in Figures 5(A) 
and 5(B). The primary difference involves processing variations that result from the 
handling of SS7 ISUP versus SS7 TCAP type messages. Most notably, since a 
TCAP message is, in fact, also an SCCP message, there is no need to directly 
encapsulate or copy and encapsulate the incoming TCAP message. Instead the 
TO^P message is simply directed from the inbound LIM 320 to the associated PRM 
34^ via the high speed IMT Bus 310, in much the same manner as the SCCP 
encapsulated ISUP lAM described in detail above. As such, Figure 7 presents a flow 
ch^rt of the major steps associated with the processing of a TCAP-type presence 
registration request message, which may be used in conjunction with the schematic 
diagram shown in Figure 4 to better understand the TCAP based presence 
registration message generation methodology.— 




Please replace the paragraph beginning at page24^line 16, with the following 

IcWMlldi fJaldyidfJll. 




-In step ST6, the TCAP MSU is received and examined by SCRC process 
342 that is resident on PRM 340. SCRC process 342 examines the message, 
determines that presence registration service is indicated, and fonwards the TCAP 
MS U to the PRMG process 344. As indicated in step ST7, the content of the TCAP 
melssage is examined to detemnine whether the TCAP presence registration request 
recuires the generation of a SIP-formatted message. In this example, it is assumed 
that the TCAP registration request message requires a SIP-fomnatted response and, 
as such, is subsequently directed to SIP application 348 for further processing. SIP 
api)lication 348 examines the TCAP MSU and, using information contained within the 
MSU, generates a SlP-fomatted presence registration message (ST8).- 

-[-Please replace the paragraph beginning at page_25, line^S, with the following \ 
revmtten paragraph: ^-^^^^^ 

! 
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-With SIP processing complete, the SIP-fomfiatted presence registration 
message is passed to HMRT process 350. HMRT process 350 determines to which 
ACjCM card the SIP registration message packet should be routed for subsequent 
outbound transmission {ST9). In this case, the HMRT process 350 detemnines that 
th^ desired outbound signaling link associated with the routing of the SIP registration 
message is located on ADCM 360. Consequently, the SIP message packet is 
internally routed across the IMT bus 310 to LIM 360, where it is received by I/O 
qu^ue 362 (ST10). Eventually, the modified message packet is passed from I/O 
qu^ue 362 on to the IP Level 2 and Level 1 processes 364 and 366, respectively 
(Stil). As indicated in step ST12, the SIP-formatted presence registration message 
is ^hen transmitted into an IP network for ultimate delivery to and use by a presence 
dajabase system.- 

Please replace the paragraph beginning at page^, line 16, with the following 
revj^ritten paragraph: _ 



-Shown in Figures 8, 9 and 10 are simplified network diagrams that illustrate 
example implementations of the embodiments described above. More particularly, 
Figjure 8 illustrates an implementation of the presence registration and routing node 
3o|) of the present invention in a mobile or wireless telecommunications environment, 
gejierally indicated by the numeral 400. Network 400 includes a mobile subscriber 

40^, a base station complex 404, a mobile switching center (MSC) 406, a home 

i 

locjation register (HLR) 408, and a presence server 410. It will be appreciated that 
the message flows shown in Figure 8 indicate that the presence registration and 
routing node 300 formulates and transmits a presence registration message 416 in 
resjponse to the receipt of a location update message 412 that is sent from the MSC 
40i>. Those skilled in the art of wireless telecommunications will appreciate that an 
M^C performs a number of functions in a wireless network, including the formulation 
an(J routing of signaling messages. In the example shown in Figure 8, the location 
up(|Jate signaling message used by the presence registration and routing node 300 to 
trigger the presence registration message 416 is destined for HLR node 408. In such 



I vj^ir 



a vfireless scenario, the presence registration message 416 could be formulated and 
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tra^ismitted by the presence registration and routing node in response to a mobile 
loqation update message associated with the registration of a wireless customer in a 
particular cell or service area. Once again, those skilled in the art of wireless or 
mobile telecommunications will appreciate that wireless or mobile signaling 
messages are generated and transmitted within a wireless network in response to the 
powering-up or turning-on of a customer's wireless phone, as well as in response to 
int^r-cell movement of a mobile subscriber during the course of a mobile call. As 
such, the presence registration and routing node of the present invention facilitates a 
method of presence registration that is completely transparent to the cell or mobile 
phjDne user.- 

^----''''''^ Please replace the paragraph beginning at p age 2 6, line 19, with the following |7 
re\^ritten paragraph: J 

---""^'^ -Figure 9 illustrates an implementation of presence registration and routing 
no^e 300 of the present invention in a wired telecommunications environment, 
gefierally indicated by reference numeral 420. Network 420 includes a wireline 
sul[)scriber 422, an end office (EO) 424, and a presence server 426. It will be 
aplDreciated that the message flows shown in Figure 9 indicate that presence 
registration and routing node 300 fonnulates and transmits a presence registration 
message 434 in response to the receipt of an ISUP call signaling message from EO 
42jt. More particularly, presence registration message 434 is generated in response 
to jhe receipt of an ISUP Initial Address Message (lAM) message 428. Those skilled^ 

in jhe art SS7 signaling will appreciate that an ISUP lAM message is the first in a 

I 

se({iuence of ISUP formatted SS7 call control signaling messages that are required to 

corjnplete a phone call in the Public Switched Telephone Network (PSTN). As such, it^ 

wilj be appreciated that in the scenario illustrated in Figure 9, presence registration 

message 434 is formulated in response to an attempt by wireline subscriber 422 to 

place a telephone call. As presence registration message generation is triggered by 

an ISUP lAM message, it will be appreciated by those skilled in the art of SS7 

tele^communications that completion of an attempted telephone call is not required in 

order for a presence registration message to be generated and transmitted to a 
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presence server. Thus, any call attempts by wireline subscriber 422 will effectively 
register the subscriber's presence with presence server 426 via presence registration 
antl routing node 300 of the present invention. It will also be appreciated from Figure 
9, that triggering ISUP lAM message 428 is subsequently routed to a destination 
adjjress specified in the message.— 




J"^'^^^ Please replace the paragraph beginning at page 27, line 20, with the following \ 
re\(\/ritten paragraph: y 

"^"^^^ -Shown in Figure 10 is a variation of the scenario that was illustrated in Figure 
9 vi^hereby an SS7 signaling message used to trigger the fomiulation and subsequent 
trajismission of a presence registration message is comprised of a TCAP-type 
message instead of an ISUP-type message. Shown in Figure 10 is an 
implementation of presence registration and routing node 300 of the present 
in\^ention in a wired telecommunications environment, generally indicated by 
reference numeral 440. Network 440 includes a wireline subscriber 442, an end 
offjce (EO) 444, and a presence server 446. In the particular embodiment shown in 
Ficjure 10, it is assumed that the wireline subscriber 442 indirectly initiates a TCAP 
message 448 by dialing "*88" or a similar code on a telephone keypad. Once again, 
thcjse skilled in the art of SS7 telecommunication networks will appreciate that 
gefieration of such TCAP messages is accomplished by an End Office (EO) or 
Se^ice Switching Point (SSP) in response to the "*88" keystrokes, as generally 
indjicated in Figure 10. As such, by dialing "*88" wireline subscriber 442 is effectively 
manually registering his or her presence with the presence server via the generation 
of the TCAP message 448, which in turn causes the generation of a presence 
registration message 450 by presence registration and routing node 300 of the 
preseni inveniion.-- 


L 


1 Please replace the paragraph beginning at page 28, line 16, with the following 

icwiiiidi iJdiciyi dpi 1. 






-The embodiments of the present invention described in detail above can be 

easily extended to include a presence registration and routing node that is capable of 

majintaining a presence database system. One embodiment of such a presence 
\ -12- 
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registration and routing node is illustrated in Figure 11, and generally indicated by 
reference numeral 500. It will be appreciated that in the particular embodiment 
presently contemplated, presence registration messages are not fomriulated and 
roijited from the node. Instead presence registration takes place at or within the 
node. That is, in the embodiment of the present invention shown in Figure 11 and 
described below, the functionality of a presence server is included within presence 
registration and routing node 500.~ 

Please replace the paragraph beginning at page 29riine 3, with the following 
l^re^n^en paragraph: ^^^^"^ 

-With particular regard to the embodiment illustrated in Figure 11 and in a 
manner similar to the embodiment described above, it will be appreciated that 
presence registration and routing node 500 includes a high speed Interprocessor 
Mejssage Transport (IMT) communications bus 310. Communicatively coupled to 
IM]r bus 310 are a number of distributed processing modules or cards including a 
pa(r of Maintenance and Administration Subsystem Processors (MASPs) 312, an 
S97 capable Link Interface Module (LIM) 320, an IP capable Advanced Database 
Co|nmunication Module (ADCM) 360, and a Presence Database Module (PDM) 502. 
Th^e modules are physically connected to the IMT bus 310 such that signaling and 
oth|er type messages may be routed intemally between all active cards or modules. 
Fo( simplicity of illustration, only a single LIM 320, ADCM 360, and PDM 502 are 
inc|uded in Figure 11. However, it should be appreciated that the distributed, multi- 
prcjcessor architecture of the presence registration and routing node 500 facilitates 
the| deployment of multiple LIM, ADCM, PDM, and other cards, all of which could be 
simuiianeousiy connecxeu lo ine iivi i dus otu.— 






Please replace the paragraph beginning at page 29, iine_24, with the following 

rpwrittpn rtriranrsnh' 

idfyiikidi ^cii ci^i ci|k^i 1 ■ 




! -Once again, it will be appreciated that LIM 320 is comprised of a number of 
sull-component processes including, but not limited to an SS7 MTP level 1 process 
32^, an SS7 MTP level 2 process 324, an I/O buffer or queue 325, a gateway 
screening (GWS) process 326, a Presence Server Request (PRR) stop action 

: -13. 
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process 328, an SS7 MTP level 3 layer HMDC process 330, and an HMDT process 
33^. MTP level 1 and 2 processes 322 and 324, respectively, provide the facilities 
nepessary to send and receive digital data over a particular physical media / physical 
interface, as well as to provide error detection / correction and sequenced delivery of 
all' SS7 message packets. I/O queue 325 provides for temporary buffering of 
inqoming and outgoing signaling message packets. GWS process 326 is responsible 
for examining the incoming signaling message and determining which, if any, of the 
pr(>visioned stop actions are applicable. PRR stop action process 328 is responsible 
for making a copy of, and subsequently encapsulating, an incoming SS7 ISDN User 
P^rt (ISUP) lAM signaling message packet within an SS7 Signaling Connection 
Ccjntrol Part (SCCP) formatted packet. It should be appreciated that PRR stop action 
process 328 could also be configured to simply encapsulate the original incoming 
SSj7 ISUP lAM signaling message, without making a copy. MTP level 3 HMDC 
prdcess 330 receives signaling messages from the lower processing layers and 
pejforms a discrimination function, effectively detennining whether an incoming SS7 
message packet requires internal processing or is simply to be through switched. For 
in^bnce, in the case of an SS7 TCAP message associated with presence registration 
or an SCCP encapsulated ISUP lAM message, HMDC process 330 would detemriine 
thsjt the message should be internally routed for further processing. HMDT process 
33^ manages or directs the internal routing of SS7 message packets that require 
additional processing prior to final routing. Once again, it should be appreciated that 
a LjiM card may contain more functional processes than those described above. The 

i 

ab|}ve discussion is limited to LIM functionality associated with the basic processing 

1 

or (n-DOuna signaling messages.— - 




Please replace the paragraph beginning at page 31, line 15, with the following 
revmtten paragraph: — - 




-The processes explicitly shown on out-bound ADCM 360 include an I/O 
qu^ue 362 and IP level 1 and 2 processes 366 and 364, respectively. I/O queue 362 
facjilitates temporary buffering of incoming and outgoing signaling message packets, 
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while IP addressing operations are performed by IP level 1 and 2 processes 366 and 

36id rp^npr:ti\/pl\/ 






Please replace the paragraph beginning at page 32, line 1, with the following 
re\^ritten paragraph: 




ft>^ 


"In general, a PDM card includes the database and database control 
processes necessary to facilitate the presence registration and query handling 
functionality of the contemplated embodiment of the present invention. PDM 602 
sh^wn in Figure 11 is comprised, in part, of an SCCP subsystem controller known as 
a Signaling Connection Routing Controller (SCRC) process 504, a Presence 
Da,tabase Manager (PDMG) process 510, and a number of Presence Database 
Interface (PDI) Applications generally indicated by the numeral 512. Included among 
Ppl Applications 512 are session initiation protocol (SIP) application process 518, 
IMpP application process 514, and presence protocol process 519. SCRC process 
50^ is responsible for discrimination of signaling messages and subsequent 
disjlribution of these signaling messages to an appropriate higher processing level 
ap|)lication or function. In the configuration shown in Figure 11, the next highest 
prcicessing level is represented by PDMG process 510. PDMG process 510 is 

generally responsible for determining which of the provisioned protocol-specific PDI 

1 

Applications 512 is required process the incoming message packet. For instance, if 
the| incoming presence registration packet contained a TCAP or SCCP-encapsulated 
IMlj^P message, PDMG process 510 would determine that provisioned PDI 
ap||)lication 514 was required for successful processing. As will be appreciated from 

Figure 1 1 , a number of PDI applications 512 may be simultaneously provisioned on a 

1 

single PDMG card. These protocol-specific PDI applications may be configured such 

th£^^ each application is capable of receiving presence registration or query messages 

tha^ are fomriatted in different protocols including, but not limited to, SIP, IMPP, and 

thd presence protocol. Furthermore, these PDI applications 512 are also capable of 

gerjierating or formatting protocol-specific presence service related response 

mejssages. Such a presence service response message might include, but is not 

limjted to, a message that provides presence status infonnation for a specific user in 
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response to a presence status query. This particular scenario is specifically 
illustrated in Figure 11, where the presence status query packet assumes the form of 
an SS7 TCAP-encapsulated IMPP query message and the subsequent presence 
status response is contained within a SIP fonnatted message.- 
^'''"^'''"'^ease replace the paragraph beginning at page 33, line 9, with the following^ 
' reyvritten paragraph: — ) 
i^..^^ -Once again, while any number or variety of PDl applications may be 
provisioned on a single PDM card, only IMPP, SIP, and presence protocoi PDl 
apjDlications 514, 518, and 519, respectively, are described herein. SIP PDl 
application 518 contains the logic necessary to process incoming SIP presence 
messages and constmct outgoing SIP presence response messages. Similarly, 
IMpP PDl application 514 contains the logic necessary to process incoming IMPP 
forpnatted presence messages and construct outgoing IMPP formatted presence 
response messages. Presence PDl application 519 contains the logic necessary to 
process incoming presence query messages formatted according to the presence 
prbtocol and construct outgoing presence response messages formatted according to 

the Dre^enne nrotofiol — 






1 

Please replace the paragraph beginning at page_34, line 4, with the following 

IwVVIlll^ll |hJCII Cl^l dfi^l 1. 




0 


-With particular regard to the scenario generally illustrated in Figure 11, It is 

assumed that an incoming TCAP-encapsulated IMPP formatted presence query 

mejssage is received at the inbound LIM module 320 (ST1). Once again, in steps 

STj2 and ST3, the incoming TCAP-encapsulated IMPP fonnatted presence query 

me|ssage is received and processed by the MTP Level 1 and 2 processes 322 and 

324, respectively. With MTP Level 1 and 2 processing complete, the signaling 

mejssage packet is temporarily buffered in the I/O queue 325 before being passed up 

thej stack to the MTP Level 3 Gateway Screening (GWS) process 326. As indicated 

in jstep ST4, GWS process 326 examines the incoming TCAP presence query 

mejssage and detennines not only whether the message is to be allowed into the 

swijtch for further processing, but also which, if any, of the provisioned stop actions 
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ar0 applicable to the incoming message. In the scenario shown in Figure 11, GWS 
process 326 examines the incoming TCAP-encapsulated IMPP presence query 
message and detemiines that the message is permitted to enter the switch. 
Fufthermore, upon examination of the Originating Point Code (OPC), Destination 
Point Code (DPC) and Service Indicator Octet (SIO) fields contained in the MTP 
roLjting layer, it is determined that the message does not require additional 
prc^cessing by PRR stop action 328. As such, the TCAP MSU is then routed directly 
to HMDC process 330 where SCCP type processing is performed (ST5). In the 
example shown in Figure 11, HMDC process 330 examines the message packet and 
determines that the DPC and Subsystem Number (SSN) of the TCAP packet is the 
PQ and SSN of the internal presence server database system that is located on PDM 
carjd 502. Consequently, further processing of the TCAP MSU within the routing 
node is assumed to be necessary, and the packet is passed to the HMDT process 
332. HMDT process 332 examines the Service Indicator (SI) field of the TCAP MSU, 
which indicates that the packet is of an SCCP type. As such, HMDT process 332 
places the TCAP MSU on high speed IMT bus 310 for transport to PDM 502 and 
sutj)sequent presence database service.- 

Piease replace the paragraph beginning at page 35, line 9, with the following 




revyritten paragraph 



In step ST6, the TCAP MSU is received and examined by SCRC process 
504 that is resident on PDM 502. SCRC process 504 examines the message, 
detjemnines that presence database service is indicated, and forwards the TCAP 
MSjU to PDMG process 510. As indicated in step ST7, the message packet is 
examined to determine the protocol of the presence related message. In this case, 
the| protocol of the presence related message encapsulated within the TCAP packet 
is iK/IPP. Next, in step ST8, the variety or type of presence service associated with 
the message is evaluated. Such general presence message types or varieties might 
include, but are not limited to, query and registration type messages.- 

Please replace the paragraph beginning at page 37, line 8, with the following 
rewritten paragraph: 
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"With particular regard to the ennbodiment illustrated in Figure 13 and in a 
manner similar to the embodiment described above, it will be appreciated that 
presence registration and routing node 600 includes a high speed Interprocessor 
Message Transport (IMT) communications bus 310. Communicatively coupled to 
IMT bus 310 are a number of distributed processing modules or cards including: a 
pair of Maintenance and Administration Subsystem Processors (MASPs) 312. an 
SS|7 capable Link Interface Module (LIM) 320, an IP capable Advanced Database 
Cohimunication Module (ADCM) 360, and an External Presence Database Module 
(Elf DM) 700. As further indicated in Figure 13, EPDM 700 is connected to an 
extjernal Presence Database Server platform 800 via a high-speed Ethernet-type 
cofjinection 802. In this embodiment, extemal Presence Database Server platfomn 
80() includes the actual Presence Database entity 516. With exception of EPDM card 
70^ and external Presence Database Server 800, all other functional and operational 
as||)ects of the embodiment shown in Figure 13 are identical to that of the 
ennjbodiment shown in Figure 11 and described above.- 

^-'^'^''Hease replace the paragraph beginning at page 38Jine 1, with the following ' 
revj^ritten paragraph: ^ ^ 

-In general, an EPDM card 700 includes the database and database control 
prcjcesses necessary to facilitate the presence registration and query handling 
funjctionality of the contemplated embodiment of the present invention. EPDM 700 
shcj)wn in Figure 13 is comprised, in part, of an SCCP subsystem controller known as 
a jSignaling Connection Routing Controller (SCRC) process 504, a Presence 

Da|abase Manager (PDMG) process 610, and a number of Presence Database 

I 

Interface (PDI) applications generally indicated by the numeral 512. Included among 
PD|I applications 512 are a session initiation protocol (SiP) application process 518, 
an IMPP application process 514, and a presence protocol process 519. SCRC 
projcess 504 is responsible for discrimination of signaling messages and subsequent 
disjribution of these signaling messages to an appropriate higher processing level 
apfj)lication or function. In the configuration shown in Figure 13, the next highest 
prolcessing level is represented by PDMG process 510. PDMG process 510 Is 



-18- 



serial No. 09/627,253 

generally responsible for detemiining which of the provisioned protocol-specific PDI 
applications 512 Is required process the incoming message packet. PDI applications 
512 are capable of generating or formatting protocol-specific presence service 
related response messages. Such a presence service response message might 
include, but is not limited to, a message that provides presence status information for 
a Specific user in response to a presence status query.- 



Please replace the paragraph beginning at page 39, line 10, with the following 

T~ • — 

re\|vrit ten paragraph: 



-Shown in Figure 14 is another embodiment of a presence registration and 
rotlJting node of the present invention, generally indicated by reference numeral 900. 
With particular regard to the embodiment illustrated in Figure 14 and in a manner 
similar to the embodiment described above, it will be appreciated that presence 
registration and routing node 900 includes a high speed Interprocessor Message 
Transport (IMT) communications bus 310. As in the previously described 
enr)bodiments, communicatively coupled to IMT bus 310 are a number of distributed 
prdcessing modules or cards including a pair of Maintenance. and Administration 
Su|bsystem Processors (MASPs), an SS7 capable Link Interface Module (LIM) 320, 
anjj an IP capable Advanced Database Communication Module (ADCM) 360, and a 
Presence Registration Module (PRM) 340. Further included in presence registration 
and routing node 900 is an accounting and billing subsystem which is comprised of 
an| accounting subsystem interface module (ASIM), generally indicated by reference 
nufneral 910 and an accounting server platform (ASP), generally indicated by 
reference numeral 920. It will be appreciated that the combination of ASIM card 910 
an^ ASP accounting server 920 includes the database and control processes 
ne|:essary to achieve the accounting and billing functionality of the present invention. 
Fr(j>m a practical Implementation standpoint, ASP 920 could assume the fonn of a 
Sup Workstation or similar type computing platfomi. It will be further appreciated that 
an j entire message accounting subsystem could also be integrated within a presence 
roL^ting and registration node.~ 
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Please replace the paragraph beginning at page 40, line 7, with the following 
/rewritten paragraph: " 

-ASIM card 910 shown in Figure 14 includes a Signaling Connection Control 
Part (SCCP) subsystem 912 that is responsible for receiving and preliminary 
processing of incoming SCCP encapsulated accounting message packets. ASIM 
card 910 also includes an SCCP controller known as a Signaling Connection Routing 
Controller (SCRC) process 914 and a high-speed Ethernet Controller (EC) process 
91 Once again, as described above, SCCP subsystem 912 is responsible for 
recieiving and preliminary processing of incoming SCCP encapsulated message 
packets, while SCRC process 914 is responsible for discrimination and subsequent 
distribution of messages based on information contained in an SCCP packet. In the 
ca^e of ASIM card 910, messages that satisfy the SCRC discrimination criteria are 
distributed or directed to high-speed Ethernet Controller process 916. EC process 
916 is in turn responsible for controlling the process of communicating messages, via 
an iEthernet connection to and from associated ASP server 920. More particularly, 
ASP server 920 includes a corresponding high-speed Ethemet Controller process 
92^ that serves as the communications interface between ASIM card 910 and an on- 
board accounting server manager (ASM) process 924. ASM process 924 is 
resjDonsible for the de-capsulation or removal of the SCCP envelope that contains the 
acdounting message. The de-capsulated accounting message is then passed to an 
adjacent usage and measurements process 926 where usage measurement 
statistics are created and stored in a usage measurements database (UMD) process 
93(^, such as that shown in Figure 15.- 



/I — Please replace the paragraph beginning at page line 6, with the following^ 




^re\A|ritten paragraph: 

i -Usage measurements statistics produced by such a process could include, 

butj are not limited to, peg counts of messages received from a specific network 

ad(|ress, a specific service provider, a specific service user, a specific IP socket, or a 

specific signaling link. Furthermore, information specific to the type of service 

req|Ljested, calling and called party information, and other infonnation associated with 

-20- 



serial No. 09/627.253 

a communication that could be useful in generating a bill or invoice may also be 
stdred in a UMD. As shown in sample UMD process 930, in one simplified 
endbodiment, each communication is identified by a transaction ID, and certain 
predetermined information associated with a communication can be stored in the 
database. It will be appreciated that the information contained in a UMD database 
cojjld be significantly more or less detailed than that indicated in the example shown 
in Figure 15.- 



Please replace the paragraph beginning at page 43, line 20, with the following 
rewritten paragraph: 



-Figure 16 illustrates yet another embodiment of a presence registration and 
routing node of the present invention, which extends the integrated accounting and 
billing subsystem concept to the routing node previously presented in Figure 1 1 . This 
new embodiment of a presence server and routing node is generally indicated by 
reference numeral 950. With particular regard to the embodiment illustrated in Figure 
16' and in a manner similar to those embodiments described above, it will be 
appreciated that presence registration and routing node 950 includes a high speed 
Int^rprocessor Message Transport (IMT) communications bus 310. Communicatively 
co(jpled to IMT bus 310 are a number of distributed processing modules or cards 
inc|luding a pair of Maintenance and Administration Subsystem Processors (MASPs), 
ani SS7 capable Link Interface Module (LIM) 320, and an IP capable Advanced 
Dajtabase Communication Module (ADCM) 360, and a Presence Registration Module 
(P^M) 340. Further included in the presence registration and routing node 950 is an 
accounting and billing subsystem which is comprised of an accounting subsystem 
interface module (ASIM), generally indicated by reference numeral 910, and an 
accounting server platform (ASP), generally indicated by reference numeral 920. 
Ag^in, it will be appreciated that the combination of ASIM card 910 and ASP 
ac(|)ounting server 920 includes the database and control processes necessary to 
achieve the accounting and billing functionality of the present invention.- 



/ Please replace the paragraph beginning at page_44, li ne 16 ^ with the following 
revj/ritten paragraph: 
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